HTTP 的缺點

• 通訊使用不加密明文，內容可能會被竊聽
• 不驗證通訊方身放，可能遭到偽裝
• 無法證明訊息的完整性，可能會遭到竄改

以上缺點在其他未加密協定也會存在。

通訊使用不加密明文，內容可能會被竊聽

• TCP / IP 是可能被竊聽

根據 TCP / IP 的工作機制，通訊不加密表示所有通訊線路上的資料都有可能被窺視。

網路是連接到全世界的網路組成，因此通訊線路上的電腦、光纖及其他網路上都不可能是個人所有，所以可能在某個環節上被遭到窺視。

即使經過加密處理，也會被窺視到通訊內容，跟未加密的訊息差別在於，加密的訊息有可能讓人無法理解 HTTP 訊息含義，但加密過後的訊息還是有可能被看到。

• 加密處理防止被竊聽
  在目前大家研究如何防止竊聽的對策，最普及的就是加密技術：
  • 通訊的加密：將通訊加密，HTTP 協議中沒有加密機制，但可以通過 SSL 或 TLS 的組合使用，加密 HTTP 通訊內容。用 SSL 建立安全通訊後，就可以在這條線路上進行 HTTP 通訊，稱之 HTTPS。
  • 內容的加密：將 HTTP 訊息內容作加密，而客戶端和伺服端都要同時具備加密及解密機制。不同於 SSL 或 TLS ，內容仍然有被竄改的風險。

不驗證通訊方的身份就會遭到偽裝

HTTP 協議中的請求與回應不會對通訊方進行確認，也就是可能會發生伺服端或客戶端的其中一方是偽造的狀況。

• 任何人都可發送請求
  在 HTTP 通訊中，由於不存在確認通訊方的處理步驟，在 IP 位置和埠號沒限制的狀況下，無論是誰發送請求，伺服端都會接收請求，所以可能有以下的隱患：

  • 無法確認發送請求的對象是否為目標伺服端。
  • 無法確認接收請求的對象是否為目標客戶端。
  • 無法確認正在進行通訊的那方是否有具備訪問權限。

• 查明對方的憑證
  雖然 HTTP 無法確認對方身份，可是 SSL 可以，而且使用了憑證的方法來確認。憑證由第三方機構頒發，來證明客戶端和伺服端是真實存在。因為偽造憑證很困難，所以確認對方的憑證就可以判斷，而且對使用者來說可以減少訊息洩漏的危險。

無法證明訊息完整性，可能已遭竄改

這邊的完整性講的是訊息的準確度。

• 接收到的內容可能有誤
  由於無法證明 HTTP 訊息的完整性，因此在請求（或回應）後到對方接收的這段時間，如果內容被竄改也沒辦法知道。意思就是你送出的請求（回應）和另一端接收到的請求（回應），在傳輸過程中可能會遭人篡改，像這樣的模式叫做 MITM（Man-in-the-Middle attack）。
• 如何防止竄改
  雖然有使用 HTTP 協議確認 HTTP 訊息的完整性，但事實上並不可靠，比較常用的是 MD5 和 SHA-1 等散列值檢驗來確認文件的數位簽名。

HTTP + 加密 + 認證 + 完整性保護 = HTTPS

HTTP 加上加密處理與認證等完整保護就是 HTTPS

如果在傳輸過程中使用未加密明文，那麼在頁面上串金流就也可能會被竊聽，那一些金融資料就可能會被曝露，另外沒辦法確認對方身份也很麻煩，所以為了統一解決上述問題，就需要在 HTTP 上做加密處理，因此把加密及認證機制稱作 HTTPS。

https://...

HTTPS 是身披 SSL 外殼的 HTTP

HTTPS 不算是在應用層的新協議，只是通訊端用 SSL 和 TLS 協議替代，通常使用 HTTP 是直接和 TCP 層通訊，但 HTTPS 使用 SSL ，就變成 SSL 在跟 TCP 通訊，這樣的感覺就像在 TCP 和 HTTP 中間多了一層 SSL。

SSL 是獨立於 HTTP 協議，所以應用層的 SMTP 和 Telent 等等協議都可以配合。

相互交換密鑰的公開密鑰加密技術

SSL 採用公開密鑰加密的加密處理方式，現在的加密方法是公開的，但是密鑰是保密的，加密和解密都會用到密鑰，換句話說有密鑰就可以解密。

• 共享密鑰加密的困境

加密和解密共用同個密鑰叫做共享密鑰加密，又稱為密鑰加密。

以共享密鑰加密的方式把密鑰傳送給對方，但在傳送的過程也可能會被遭到攻擊，如果密鑰被攻擊者知道就失去意義，那我們該如何安全傳輸密鑰呢？

• 使用兩把密鑰的公開密鑰加密
  公開密鑰加密的方式解決了共享密鑰加密的困難。

  公開密鑰加密：有一把非對稱的密鑰，一把叫做私有密鑰（私鑰），一把叫做公開密鑰（公鑰），意思就是私有密鑰不能給別人知道，公開密鑰可以讓任何人知道。

  過程：發送密文的那方使用接收方的密鑰進行加密處理，對方收到加密的訊息再用自己的私鑰進行解密。

  這樣的方式就不用擔心訊息被竊盜，另外如果想根據密文和公鑰來解密是非常困難的，因為解密的過程就是對離散數學求值，密碼還是有機會遭到破解，但就現在的技術而言是不太可能的。

• HTTPS 採用混合加密機制

  HTTPS 採用共享密鑰加密和公開密鑰加密兩者並用的混合加密機制，如果密鑰能夠安全交換，那麼就有可能會用公開密鑰的方式來進行通訊，但公開密鑰比共享密鑰加密的方式還慢。

證明公開密鑰正確性的證書

公開密鑰還是有問題，就是無法證明公開密鑰本身的真實性，舉例來說：

準備和某台主機建立公開密鑰加密的方式，來進行通訊傳輸，如何確認公開密鑰就是原本那台伺服器發送的公開密鑰，因為有可能在公開密鑰傳輸的過程中被攻擊者替換。

為了解決上述問題，可以使用數位憑證認證機構，與相關機關頒發的公開密鑰證書。

• 數位憑證認證機構：客戶端與伺服端雙方都可信任的第三方機構。
• 流程：伺服器的營運人員先向第三方申請公開密鑰的申請，數位憑證機構判明提出申請者的身份，在對已申請的公開密鑰做數字簽名，然後再分配這個已簽名的公開密鑰，並將公開密鑰放入公鑰證書後並綁定。
• 伺服端：伺服端會把這份數位憑證機構頒發的公鑰發送給客戶端，以做公鑰密鑰加密的方式通訊，公鑰憑證也可以叫做數位憑證。
• 客戶端：接收到數位憑證的客戶端，可以使用公鑰對數位憑證進行驗證，驗證通過即可證明認證伺服器的身份以及其公鑰是可以信賴。

數位憑證的公鑰要安全地交給客戶端是困難的事，因此瀏覽器商在發布版本的時候，會事先在內部植入常用的數位憑證機構的公鑰。

客戶端作業順序：

1. 使用瀏覽器植入的公開密鑰
2. 拿到伺服器的數位憑證後，用瀏覽器的公開密鑰做驗證
3. 驗證過後使用公開密鑰對 HTTP 訊息做加密後傳輸

伺服端作業流程：

1. 伺服器把自己的公開密鑰登錄到數位憑證機構
2. 接收到請求方的請求後，伺服端用私鑰對加密的請求進行解密

• 可證明組織真實性的 EV SSL 證書

憑證是來證明其中一方的身份，再來就是確認伺服器規模。擁有該特性的憑證就是 EV SSL 憑證。

EV SSL 數位憑證基於國際標準，嚴格規定了對營運組織的確認方針，因此通過的網站可以獲得比較高的認可度。擁有 EV SSL 數位憑證的瀏覽器，在瀏覽器 URL 欄位的背景色是綠色，為的是防止釣魚攻擊。

• 用以確認客戶端的客戶端證書

  HTTPS 中還可以使用客戶端憑證，證實伺服器正在通訊的那方是預期的客戶端，作用和伺服端憑證相同，但仍然有幾個問題點：

  • 憑證的頒發與獲得：要拿到證書意味要付費購買，讓不同用戶自行安裝憑證這件事就具有很大的挑戰。現況是安全性比較高的憑證機構可以頒發客戶端憑證，但僅限於特殊用途，像是可以支付憑證的業務。像是網路銀行就常使用客戶端憑證。
  • 無法獲得用戶本人的真實性：就算確認了電腦，但不能代表使用電腦的人就是擁有憑證的本人。

• 認證機構信譽第一
  SSL 機制之所以可行，是因為認證機構是可被信賴的，之前在荷蘭有被爆出憑證機構被駭客入侵。雖然現在有將憑證吊銷的機制，以及從客戶端刪除憑證發布機構的對策，但距離完全實現還需要一點時間。

• 由自認證機構頒發的證書稱為自簽名證書
  使用 Open SSL 每個人可以建立自己的數位憑證，給自己的伺服器憑證，但在網路上是不可以使用，如果瀏覽器訪問該網站就會出現「無法確認連接安全」或「此網站憑證存在問題」等等，主要是因為無法消除偽裝可能性的關係。

HTTPS 的安全通信機制

• SSL 和 TLS
  IETF 以 SSL 3.0 為基準，後來又制訂了 TLS 1.0 及 TLS 1.1 的版本，目前主流的是 SSL 3.0 和 TLS 1.0。
• SSL 速度慢嗎
  • 通訊慢：和 HTTP 比，網路負載會慢 2-10 倍，TCP 連接、發送 HTTP 請求、回應也都要進行 SSL 通訊，所以通訊量也會增加。
  • 效能慢：因為需要進行加密處理，伺服端和客戶端都需要進行加密和解密的過程，就結果來說 SSL 會消耗更多伺服器和客戶端的硬體資源。

為什麼不一直用 HTTPS 就好？其實只要與個人資訊相關等敏感資料再做加密通訊就好，除了上述缺點外，節約開銷也是重點。

資料來源：《圖解 HTTP》 上野宣 人民郵電出版社
筆記純屬推廣及分享，如有侵權，請告知。
Please advise to remove immediately if any infringement caused.